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Periodic control systems used in spacecrafts and automotives are usually period-driven and can be 
decomposed into different modes with each mode representing a system state observed from outside. 
Such systems may also involve intensive computing in their modes. Despite the fact that such control 
systems are widely used in the above-mentioned safety-critical embedded domains, there is lack of 
domain-specific formal modeling languages for such systems in the relevant industry. To address 
this problem, we propose a formal visual modeling framework called MDM as a concise and precise 
way to specify and analyze such systems. To capture the temporal properties of periodic control 
systems, we provide, along with MDM, a property specification language based on interval logic for 
the description of concrete temporal requirements the engineers are concerned with. The statistical 
model checking technique can then be used to verify the MDM models against the desired properties. 
To demonstrate the viability of our approach, we have applied our modeling framework to some real- 
life case studies from industry and helped detect two design defects for some spacecraft control 
system. 

1 Introduction 

The control systems that are widely used in safety-critical embedded domains, such as spacecraft control 
and automotive control, usually reveal periodic behaviors. Such periodic control systems share some 
interesting features and characteristics: 

• They are mode-based. A periodic control system is usually composed of a set of modes, with each 
mode representing an important state of the system. Each mode either contains a set of sub-modes 
or performs controlled computation periodically. 

• They are computation-oriented. In each mode, a periodic control system may perform control 
algorithms involving complex computations. For instance, in certain mode, a spacecraft control 
system may need to process intensive data in order to determine its space location. 

• They behave periodically. A periodic control system is reactive and may run for a long time. The 
behavior of each mode is regulated by its own period. That is, most computations are performed 
within a period and may be repeated in the next period if mode switch does not take place. A mode 
switch may only take place at the end of a period under certain conditions. 
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ModeDiagram Framework 

Property Specifications 

PI. □(-.m/t ■^m^ '^^rriA ^ I > 600s) 

P2. O^m^A^-^failure'^ failure)'^tt ^ m4A{-'failure'^ (failure Al < 100))'"m^tt) 




Figure 1 : MDM: An (Incomplete) Example 



Despite the fact that periodic control systems have been widely used in areas such as spacecraft con- 
trol, there is a lack of a concise and precise domain specific formal modeling language for such systems. 
In our joint project with China Academy of Space Technology (CAST), we have started with several ex- 
isting modeling languages but they are either too complicated therefore require too big a learning curve 
for domain engineers, or are too specific/general, therefore require non-trivial restrictions or extensions. 
This motivates us to propose a new formal but lightweight modeling language that matches exactly the 
need of the domain engineers, the so-called Mode Diagram Modeling framework (MDM). 

Although the proposed modeling notation MDM can be regarded as a variant of Statecharts lITTI . it 
has been specifically designed to cater for the domain-specific need in modeling periodic control systems. 
We shall now use an example to illustrate informally the MDM framework, and leave the formal syntax 
and semantics to the next section. As shown in Fig[T] the key part of an MDM model is the collection 
of modes given in the mode level. Each mode has a period, and the periods for different modes can 
be different. A mode can be nested and the transitions between modes or sub-modes may take place. 
A transition is enabled if the associated guard is satisfied. In MDM, the transition guards may involve 
complex temporal expressions. For example, in the transition from mode G2 to mode m6, in addition 
to the condition SK12=10, it also requires that the condition gm=2 has held for 40s, as captured by the 
duration predicate. 



Zheng WANG et al. 



137 



An MDM model is presented hierarchically. A mode that does not contain any sub-mode (termed a 
leaf mode.) contains a control flow graph (CFG) encapsulating specific control algorithms or computation 
tasks. The details of CFGs are given in the CFG level. The CFGs may refer to modules (similar to 
procedures in conventional languages) details of which are given in the module level. 

To support formal reasoning about MDM models, we also provide a property specification language 
inspired by an interval-like calculus ||7], which facilitates the capture of temporal properties system 
engineers may be interested in. Two example properties are listed in Fig[T] The property PI says that 
"whenever the system enters the m4 mode, it should stay there for at least 600s". The formal details of 
the specification language is left to a later section. 

To reason about whether an MDM model satisfies desired properties specified by system engineers 
using the property specification language, we employ statistical model checking techniques f23] l24l . 
Since MDM may involve complex non-linear computation in its control flow graph, complete verifi- 
cation is undecidable. Apart from incompleteness, statistical model checking can verify hybrid systems 
efficiently U- Our experimental results on real-life cases have demonstrated that statistical model check- 
ing can help uncover potential defects of MDM models. 

In summary, we have made the following contributions in this paper: 

• We propose a novel visual formal modeling notation MDM as a concise yet precise modeling 
language for periodic control systems. Such a notation is inspired from the industrial experiments 
of software engineers. 

• We present a formal semantics for MDM and a property specification language to facilitate the 
verification process. 

• We develop a new statistical model checking algorithm to verify MDM models against various 
temporal properties. Some real-life case studies have been carried out to demonstrate the effec- 
tiveness of the proposed framework. Furthermore, the design defects of a real spacecraft control 
system are discovered by our approach. 

The rest of this paper is organized as follows. Section |2]presents the formal syntax and semantics 
of MDM. Section |3]introduces our interval-based property specification language and its semantics. The 
statistical model checking algorithm for MDM is developed in Section |4l followed by related work and 
concluding remarks. 

2 The MDM Notations 

Before developing the formal model of M D M , we will begin by giving its informal description. An MDM 
model is composed by several modes, variables used in the mode, and mode transitions specifying the 
mode switch relations. A mode essentially refers to the state of the system which can be observed from 
outside. The mode body can be either a Control Flow Graph (CFG), which prescribes the computational 
tasks the system can perform in every period, or several other modes as sub-modes. If the mode has 
sub-modes, when the system is in this mode, it should be in one of its sub-modes. We say that the mode 
is a leaf mode if its mode body is a control flow graph. A leaf mode usually encapsulates the control 
algorithms involving complicated computations. The CFG in a leaf mode follows the standard notation, 
which contains assignment, conditional and loop. It also supports function units similarly to the ones in 
programming languages. 
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Body 
Transition 
Module 



md 
Mode 



{name, period, initial. 

Body, Transition^) 
Mode+ I CFG 



{Var^ ,Mode^ , Module^) 



BTerm 
lExpr 
GTerm 
BExpr 



SExpr 



: = Const \Var\ /(") {SExpr . . .) 

:= true I false I /?'^")(5'£'x/?r. . .) 

:= (after | duration) {BTerm, SExpr) 

:= lExpr I BTerm 

:= BTerm \ -iBExpr 



{source , guard, priority , target) 
{name, Vi,Vo, CFG) 



guard 



BExprV BExpr \ BExpr A BExpr 
::= GTerm \ -iguard 



(a)MDM 



I guardW guard \ guard /\ guard 
(b) Expressions and Guards 



CFG 



stmts 

pStmt I cStmt 

aStmt I call name | skip | 

X '.= SExpr 

stmts; stmts \ while BExpr do stmts 
if BExpr then stmts else stmts 



stmts 



pStmt 
aStmt 
cStmt 



(c) CFG 



Figure 2: The Syntax of MDM 



2.1 The Syntax of MDM 

We briefly list its syntactical elements in Fig. |2ta). An MDM is composed of a list of modes (Mode^) 
and modules (Module^), as well as a list of variables (Var^) used in those modes and modules. 

Intuitively, a mode refers to a certain state of the system which can be observed from outside. A 
mode has a name, a period, a body and a list of transitions. For simplicity, we assume all mode names 
are distinct in an MDM model. The mode period (an integer number) is used to trigger the periodic 
behavior of the mode. The initial denotes a mode is an initial mode or not. The mode body can be 
composed of either a control flow graph (CFG), prescribing the computational tasks the system can 
perform in the mode in every period, or a list of other modes as the immediate sub-modes of the current 
mode. If a mode has sub-modes, when the control lies in this mode, the control should also be in one 
of the sub-modes. A leaf mode does not have sub-modes, so its body contains a CFG. A mode is either 
a leaf mode, or it directly or indirectly has leaf modes as its sub-modes. A mode is called top mode if 
it is not a sub-mode of any other mode. The CFG in a leaf mode is the standard control flow graph, 
which contains nodes and structures like assignment, module call, conditional and loop. It also supports 
function units like the ones in conventional programming languages. The syntax of CFG is presented in 
Figure lll^c). 

A module encapsulates computational tasks as its CFG. Vj specifies the set of variables used in the 
CFG, while Vq is the set of variables modified in the CFG. A module can be invoked by some modes or 
other modules. As a specification for embedded systems, recursive module calls are forbidden. 

A transition (from Transition^) specifying a mode switch from one mode to another is represented 
as a quadruple, where the first element is the name of the source mode, the second specifies the transition 
condition, the third is the priority of the transition and the last element is the name of the target mode. 
The MDM supports mode switches at different levels in the mode-hierarchy. The transition condition 
(i.e. guard) is defined in Fig. |2lb). A state expression can be either a constant, a variable, or a real- 
value function on state expressions. A boolean term is either a boolean constant, or a predicate on state 
expressions. There are two kinds of interval expressions, after and duration. These interval expressions 
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are very convenient to model system behaviors related with past states. A guard term can be either an 
interval expression, or a boolean term. A guard is the boolean combination of guard terms. To ensure 
that the mode switches be deterministic, we require that the priority of a transition has to be different 
from the others in the same mode chain: 

Vm e Mode ■\/ti,t2 G outs(super_modes(mi/,m)) ■h^t2^ prio(ti) ^ prio(t2) 

The functions super_modes(m^/,m) and ouX.s{mlist) will be defined later. 

2.1.1 Auxiliary Definitions 

Given an MDM md::= {Var^ ,Mode^ , Module^), we introduce two auxihary relations: 
Contains{md) C Modes x Modes for mode-subsume relation and 
Trans{md) C Modes x Int x guard x Modes for mode-switch relation. 

Given a mode m = {n,per,ini,b,tran) and a transition t = {m,g,pri,m'), we define these opera- 
tions/predicates: 

period(m) = per isJnitial(m) = ini CFG(m) = b 

prio(t) = pri guard(t) = g source(t) = m target(t) = m' 

We also define the following auxiliary functions: 

super_modes(mJ,m) = {mi,m2,---,mk), where 

ntk = m Ami £ TopModes{md) A VI <i<k • {nii^ i,mi) £ Contains (md) 
and mETopModes{md) = mE:Modes{md)A-'3m' ■ {m' ,m)£Contains{md) 

up_mocies{md,m,k) = {m,- | m, G super_modes(mJ,m) A mod (k, period (m)* ) ~ ^} 

sub_mode(m<i,m) =m', where {m,m') G Contains{md) A'\sjn\t'\a\{m') 

outs{md,mlist) = Umemtoi^ I ^ ^ Trans{md) Asource(f) = m} 

The function super_modes(mJ,m) retrieves a sequence of modes from a top mode to m using the 
Contains relation. The set TopModes{md) consists all the modes which are not sub-modes of any other 
mode. The function up_modes(mJ,m,A:) returns those modes in super_modes(mJ,m) whose periods are 
consistent with the period count k. An MDM requires that the period of a mode should be equal to or 
multiple to the period of its sub-modes. The function sub_mode (m<i,m) returns the initial sub-mode for 
a non-leaf node m, and the predicate is_initial(m') means that the sub-mode m' is the initial sub-mode in 
its hierarchy. The function outs(mto) returns all outgoing transitions from modes in mlist. 

2.2 The Semantics 

In order to precisely analyze the behaviors of MDM, for instance, model checking of MDM , we need its 
formal semantics. In this section, we present the operational semantics for MDM. 
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c7i-...-c7„ 1=^1 or a\ -.-.-a„ \^ g2 


C7i-. 


- On h^l ^82 




ai —.-a„ |=gi and c7i-...-c7„ 
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.--an \= duration(fe,Z) 




C7„(/) = V A3;<n • (a;(fi)+V < (7„(fi)A 








a,+i (r,s')+v > C7„(^s) Ayi<j<n - Ojijb) = true) 


al-. 


..-an h after(/7,/) 




C7„(/) = V A3/<« • ((7;(fs)+V < (J„(fi)A 








Cj+i (ri)+v > an{ts)) A (J,(/7) = true) 



Table 1 : The Interpretation of Guards 

2.2.1 Configuration 

The configuration in our operational semantics is represented as {md,m,l,pc,k,'L), where 

• md is the MDM, and m is the mode the system control currently lies in. 

• / G {Begin, Execute, End} specifies the system is in the beginning, middle, or end of a period. 

• pc £ ^ , where ^ = Ji^ U {Start, Exit, _L} is the program counter to execute the control flow graph. 
jV is used to represent the nodes in control flow graphs and Start, Exit denote the start and exit 
locations of a control flow graph respectively. If the current mode is not equipped with any flow 
graph, we use the symbol _L as a placeholder. 

• The fourth component k records the count of periods for the current mode. If the system switches 
to another mode, it will be reset to 1. The period count is used to distinguish whether a super-mode 
of the current mode is allowed to check its mode switch guard. 

• £ is a list of states of the form Yl ■ a, where a denotes the current state (cr € State = Vars^W) and 
£' represents a history of states. 

Guards The evaluation of a transition guard may depend on the current state as well as some historical 
states. Table [T] shows how to interpret a guard in a given sequence of states. The symbol ts is the abbre- 
viation of the variable timestamp. The guard duration(&, /) evaluates to true if the boolean expression b 
has been true during the time interval / up to the current moment. The guard aher{b,l) evaluates to true 
if the boolean expression b was true the time interval / ago. In this table, ft is a pure boolean expression 
without interval expressions and / is a state expression. 

2.2.2 Operational Rules 

The operational rules for MDM are given in Table |2] Here we adopt a big-step operational semantics for 
MDM, which means that we only observe the start and end points of a period in the current mode, while 
the state changes within a period are not recorded. This is reasonable since in practice engineers usually 
monitor the states at the two ends of a period to decide if it works well. In the rules, we make use of an 
auxiUary function execute to represent the execution results for the mode in one period. 

execute : '^^^{V) x^x State x M+ ^ if x State 

It receives a flow graph, a program counter, an initial state and the time permitted to execute and returns 
the state and program counter after the given time is expired. Its detailed definition is left in the report 
II22I . We now explain the operational rules: 

1. (enter). When the system is at the beginning of a period, if the current mode m has sub-modes, 
the system enters the initial sub-mode of m. 
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(enter) 



(detect) 
(execute) 

(continue) 
(repeat) 

(SWITCH) 



CFG(m) = _L 

{md, m, Begin, -Ljk,!,) — > {md,m' , Begin, pc' ,k,l.) 

^ ' h ^ r ^ ^ H ' ifCFG(m') = ± 

where m = sub_mode(ma,w) and pc = < 

l^Start, if CFG(m') ^ ± 

CFG(m) 

{md,m,Begin,pc,k,'L - a) — > {md,m, Execute, pc,k,'L-s2imp\\ng{(y)) 

execM/e(CFG(m),pc,CJ,period(m)) = {pc' ,o') 
{md, m, Execute, pc,k,'E, (y) — > {md,m,End,pc' ,k,'L') 

where Z' = Z • a'\ts >-> a{ts) + period(m)] 

pc ^ Exit 

(md,m,End,pc,k,'L) — > {md,m, Execute, pc,k,'L) 

Vf G outs(up_modes(OTt/,OT,^)) -E ^ guard(t) 
(md, m, End, Exit, k,!,) — > {md,m, Begin, Start, k+l,!,) 

3t G outs{md, up_modes{md, m,k)) ■ E ^ guard(t)A 
W Gouts{up-modes{md,m,k))-{t} ■ (E ^ guard(t') V prio(t')<prio(t)) 
(md, m, End, Exit, k,!,) — > {md,m' , Begin, pc' ,1,1,) 



where m' = target(t) and pc' 



f . ifCFG(m') = ± 
[Start, ifCFG(m')7^-L 



Table 2: Operational Semantic Rules for M DM 



2. (DETECT). When the system is at the beginning of a period, if the current mode m is a leaf mode, 
the system updates its state by sampling from sensors. The function sampling represents the side- 
effect on variables during sensor detection. The period label / is changed to be Execute, indicating 
that the system will then perform computational tasks specified by the control flow graph of m. 

3. (EXECUTE). This rule describes the behaviors of executing CFG of the leaf mode m. The function 

execute is used to compute the new state o' from a. The computation task may be finished in the 
current period and pc' = Exit holds or the task is not finished and the program counter points to 
some location in the control flow graph. The value of the timestamp variable ts in a' is equal to its 
value in state a plus the period of the mode m. 

4. (continue). This rule tells that when the computation task in leaf mode is not finished in a 

period, it will continue its task in the next period. In this case, the system is implicitly not allowed 
to switch to other modes from the current mode. When moving to the next period, sensor detection 
is skipped. 

5. (REPEAT). This rule specifies the behavior of restarting the flow graph when the computation task 
is finished in a period. When it is at the end of a period and the system finishes executing the flow 
graph {pc = Exit), if there is no transition guard enabled, the system stays in the same mode and 
restarts the computation specified by the flow graph. 

6. (SWITCH). This rule specifies the behavior of the mode transition. There exists a transition t. 
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Figure 3: A Property about Failure 

Terms d = r | v | / | . . . , 0„) 

Formulas <p,Y — tt \ff\ p{di, . . . ,6n) \ \ ^ /\Y \ 

Figure 4: The Syntax of ITL 



whose guard holds on the sequence of states £. And the priority of t is higher than that of any 
other enabled transitions. 



3 The Property Specification Language 

We adopt the Interval Temporal Logic (ITL) iflTl as the property specification language. The reason 
why we adopt the interval-based logic instead of state-based logics like LTL or CTL is that most of 
the properties the domain engineers care about are related to some duration of time. For instance, the 
engineers would like to check if the system specified by M D M can stay in a specific state for a continuous 
period of time instead of just reaching this state. Another typical scenario illustrated in Fig. |3]is that, 
"when the system control is in mode m^, if a failure occurs, it should switch to mode m% in 100 ms". 
The standard LTL formula \Il{failure Am4 =^ Ow^s) can be used to specify that "when the system is in 
mode m4, and a failure occurs, it should switch to mode nig". But the real-time feature "in 100 ms" is 
lost. Though the extensions of LTL or CTL may also describe the interval properties to some extent, it is 
more natural for the domain engineers to use interval-based logic since the intuitive chop operator C") is 
available in ITL. 

An interval logic formula can be interpreted over a time interval f7^ or over a "state interval" (a 
sequence of states) 1 17 1 . As explained later in this section, our proposed specification language will 
be interpreted in the latter way IITtI except for a small modification on the interpretation of the chop 
operator C"). 

3.1 Syntax 

The syntax of the specification language is defined in FiglH where 

• The set of terms 6 contains real-value constants r, temporal variables v, a special variable /, and 
functions f{di,...,dn) (with / being an n-arity function symbol and d\,...,dn being terms). 

• Formulae can be boolean constants {tt,ff), predicates (p{6i, . . . ,6n) with p, an n-arity predicate 
symbol), classical logic formulae (constructed using A, etc), or interval logic formulae (con- 
structed using '"). If the formula <p'~'Y holds for an interval £, it means that the interval £ can 
be "chopped" into two sub-intervals, where holds for the first sub-interval and Y holds for the 
second one. 
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, , J a„^i{ts)-aQ{ts) ifE = (Jo C7„_i 




^^(/(0i,...,0„),E)=/(^^(0i,E),...,^^(0,„E)) 



^^(p(0i,...,0„),E)=tme iff 

J^^(ff,E) =true iff 

J^;^0^,E) = false iff 

J^>(-0,E) =true iff 

jV(0Ava,E) =true iff 

J?^r(0'"r,E) =true iff 



;,(^^(0i,E),...,^^(0„,E)) 

always 

always 

^^(0,E) = false 

y^{(p,T.) = true and ,y^(v/',E) = true 
3;t<oo. E= (ao...(J*:-E')A 



J^jr(0,C7o---O'<;) =trueA J^ir(v/,E') = true 



Table 3: Interpretation of the Specification Language 



As a kind of temporal logic, ITL also provides the □ and operators. They are defined as the 
abbreviations of 



By the specification language proposed here, we can describe the properties the domain engineers 
may desire. For instance, the following property describes the scenario shown in Fig. [3] 



3.2 Interpretation 

Terms/formulae in our property specification language are interpreted in the same way as in Maszkowski 
ifTTl . where an interval is represented by a finite or infinite sequence of states (£ = aoCJi . . . a„_i . . .), 
where a,- G State. The interpretation is given by two functions (1) term interpretation G Terms x 
Intv i-> M, and (2) formula interpretation function: J^^ € Formulas x Intv i— )• {true, false}. Table [3] 
defines these two functions, where ts denotes the variable timestamp. The value of the variable timestamp 
increases with the elapse of the time, i.e., for any two states in the same interval Oi,Oj, if i<i, then 
Oi{ts)<Oj{ts). Thus, we can compute the length of time interval based on the difference of the two 
time stamps located in the first and last states respectively. The interpretation of a variable v on £ is the 
evaluation of v on the first state of £. Note that our chop operator requires that the first sub-interval of £ 
is restricted to be finite no matter whether the interval £ itself is finite or not. 



As a modelling & verification framework for periodic control systems, MDM supports the modeling of 
periodic behaviors, mode transition, and complex computations involving linear or non-linear mathemat- 
ical formulae. Moreover, it also provides a property specification language to help the engineers capture 
requirements. In this section, we will show how to verify that an MDM model satisfies properties for- 
malized in the specification language. There are two main obstacles to apply classic model checking 



00 = tf^ {(p'^ tt) , for some sub-interval , dip = -iO(~'0), for all sub-intervals 



□ (m4 A {-failure^ failure)^ tt =^m^f\ {-failure^ (failure A / < 100))^ m^^tt) 



4 MDM Verification by Statistical Model Checking 
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techniques on MDM: (1) MDM models involve complex computations like non-linear mathematic for- 
mulae; (2) MDM models are open systems which need intensive interactions with the outside. 

Our proposed approach rehes on Statistical Model Checking (SMC) HQI |23l [161 [H. SMC is a 
simulation-based technique that runs the system to generate traces, and then uses statistical theory to 
analyze the traces to obtain the verification estimation of the entire system. SMC usually deals with the 
following quantitative aspect of the system under verification 1231 : 

What is the probability that a random run of a system will satisfy the given property 0? 

Since the SMC technique verifies the target system with the probability estimation instead of the 
accurate analysis, it is very effective when being applied to open and non-linear systems. Because SMC 
depends on the generated traces of the system under verification, we shall briefly describe how to simulate 
an MDM and then present an SMC algorithm for MDM. 

4.1 MDM Simulation 

The MDM model captures a reactive system flOl. The MDM model executes and interacts with its 
external environment in a control loop in one period as follows: (1) Accept inputs via sensors from the 
environment. (2) Perform computational tasks. (3) Generate outputs to drive other components. The 
MDM simulation engine simulates the process of the control loop above. 

Generally speaking, the simulation is implemented according to the inference rules defined in Ta- 
ble [2] However, the behaviors of an MDM model depends not only on the MDM itself, but also on the 
initial state and the external environment. When we simulate the MDM model, the initial values are ran- 
domly selected from a range specified by the control engineers from CAST. As a specification language, 
the type of variables defined in MDM can be real number. To implement the simulation, we use float 
variables instead, which may introduce some problems on precision. There are lots of techniques can be 
adopted to check if any loss of precision may cause problems fT4l. Because the simulation doesn't take 
care of the platform to deploy the system specified by the MDM, the time during simulation is not the 
real time, but the logic time. For each iteration in the control loop, the time is increased by the length of 
period of the current mode. 

To make the simulation be executable, we have to simulate the behaviors of the environment to make 
the MDM model to be closed with its environment. The environment simulator involving kinematic 
computations designed by the control engineers is combined with the MDM to simulate the physical 
environment the MDM model interacts with. In the beginning of each period, the simulator checks 
whether there are sub-modes in the current mode. If so, the simulator takes the initial sub-mode as the 
new current mode. When the current mode is a leaf mode, the simulator invokes the library simulating 
the physical environments and updates the internal state by getting the value detected from sensors. Then 
the simulator executes the control flow graph in the leaf mode. We assume that there is enough time to 
execute the CFG. The situation that tasks are allowed not to be finished in one period is not considered 
during simulation. In the end of each period, the guards of transitions are checked. The satisfactions of 
duration and after guards do not only depend on the current state, but also the past states. The simulator 
sets a counter for each duration/after guard instead of recording the past states. As an MDM model is 
usually a non-terminating periodic system, the bound of periods is set during the process of simulation. 

4.2 SMC Algorithm 

We apply the methodology in [23] to estimate the probability that a random run of an MDM will satisfy 
the given property (p with a certain precision and certain level of confidence. The statistical model check- 
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output 
begin 



input 



md\ the MDM, 0: property, B\ bound of periods 
8: confidence, e: approximation 

p: the probability that holds on an arbitrary run of md 



10 
20 
30 
40 
50 
60 
70 
end 



for / := 1 to A/^ do 

generate an initial state sq randomly 

simulate the MDM from 5^0 in B periods to get the state trace E 
if (J^!^((^,r) = true) then a:=a + \ 



end for 



return ^ 



Figure 5: Probability Estimation for MDM 



ing algorithm for MDM is illustrated in Fig. |5] Since the run of the MDM usually is infinite, the users 
can set the length of the sequence by the number of periods based on the concrete application. This algo- 
rithm firstly computes the number N of runs based on the formula N :=A* log(l/5)/£^ which involves 
the confidence interval \p — 8,p + 5] with the confidence level 1 — £. Then the algorithm generates the 
initial state (line 30) and gets a state trace £ by the inference rules defined in Table |2] (line 40). The 
algorithm in line 50 decides whether holds on the constructed interval based on the interpretation for 
the specification language mentioned in Section [3] If the interpretation is true, the algorithm increases 
the number of traces on which property holds. Line 70 returns the probability for the satisfaction of 
on the MDM. 

4.3 Experiments 

We have implemented the MDM modeling and verification framework and applied it onto several real 
periodic control systems. The implementation framework of SMC is illustrated in Fig.[6l where the sim- 
ulator is used to simulate the MDM by the proposed operational semantics and the generated traces are 
for the statistical model checker. One of the real periodic control systems (termed as A) is for spacecraft 
control developed by Chinese Academy of Space Technology. Fig. [flshown in Section 1) is a small 
portion of the MDM model for system A. 

We communicate with the engineers in CAST, summarize several properties the two models of space- 
crafts should obey, and present these properties in our specification language. A total of 12 properties are 
developed by the engineers and these properties are verified on the systems A. We only highlight three 
properties because the verification results on these three properties reveal two defects. 

• After 3000 seconds, the system will eventually reach the stable state forever 



where cOx, (Ox and co^ are angles, (bx, (bx and <b^ are angle rates. 

• The system starts from mode mO, and then it will finally switch to mode m5 or m6 or mS, and stay 
in one of these three modes forever 



e > 3000 tt^UUco} + 0)2 + < 0.1 A a/ cbx^ + cb,^ + w,^ < 0.01)) 





(mode = 0)'~'tt'~ n{mode = 5 V mode = 6 V mode = 8) 
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ModeDiagram j„„„„„(j ,,^,.^,. < „„„,,,„„) 




Figure 6: The Framework of Implementation 



• Whenever the system switches to mode m4 and then leaves m4, during its stay in m4, it firstly stays 
in sub-mode GO, and then it switches to sub-mode G\, and then G2. 

□ (mode 7^ 4'~^mode = 4^mode 7^ 4 mode 7^ 4'" 
mode = 4 A (gm = O'^gm = l^gm = 2)^tt) 

For the parameters of the statistical model checking algorithm, we set the half length of confident 
interval to be 1% (5 = 1%) and the error rate to be 5% (e = 5%). Based on this algorithm, the total 
7369 traces for each control system are required to be generated to compute the probabilities during the 
verification process. 

During the verification phase by the statistical model checking on MDM, two design defects in sys- 
tem A are uncovered by analyzing the verification results: (1) A variable is not initialized properly. (2) 
A value from sensors is detected from the wrong hardware address. In the traditional developing process 
in CAST, these two defects may be revealed only after a prototype of the software is developed and then 
tested. Our approach can find such bugs in design phase and reduce the cost to fix defects. 

5 Related Work 

Our MDM can be broadly considered as a variant of Statecharts lUTI . where a mode in MDM is similar 
to a state in the Statecharts. However, we note the following distinctions: (1) In Statecharts, when a 
transition guard holds, the system immediately switches to the target state. But in MDM, mode switches 
are only allowed to be triggered at the end of a period. (2) In Statecharts, a transition guard is usually a 
boolean expression on the current(source) state; while in MDM, transition guards may involve past states 
via predicates like during and after. (3) In Statecharts, all observations on the system are the states; while 
MDM also concerns about the computation aspect of the system by means of the flow graphs provided 
in the leaf modes. 

Timed Automata are a modeling tool for the description and verification of real-time systems ||3]|2]. 
It provides the clock variable to support the time explicitly. Timed Automata only focus on the linear 
computation for time since it has nice time zone semantics supporting the timed verification. Hybrid 
Automata [2| extend the traditional automata to deal with complex computation like the difference and 
differentiation while it is not a systematic modeling tool which supports the rich modeling mechanisms 
like the hierarchy, types etc. 
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Giese et al. f8l have proposed a semantics of real-time variant of Statecharts by introducing the 
Hierarchical Timed Automata. In another work [9 1 they have presented a compositional verification 
approach to the real time UML designs. A. K. Mok et al. have developed a kind of herarchical real- 
time chart named "Modechart" |[T5l . Compared with Giese et al. lH, parallel modes are supported in 
Modechart. 

Stateflow is the Statechart-like language used in the commercial software Matlab/Simulink |T|. The 
Stateflow language enriches Statecharts to allow it to support flow-based and state-based computations 
together for specifying discrete event systems. Our MDM focuses more on periodic control systems, 
which can be regarded as a specific type of discrete event systems, and it provides the first class element 
period to facilitate the precise modeling of periodic-driven systems. The transitions in Stateflow can 
be attached with a flowchart to describe complicated computation, the MDM specifies the flow graph 
for the computation in its leaf modes. While Stateflow focuses only on the modeling aspect of the 
systems, the MDM integrates modeling and reasoning by providing a property specification language 
with a verification algorithm. 

Some researchers introduce operational modes lITSl [T9l during the modeling in hardware/software 
co-synthesis. The operational mode is essentially a state in the automaton, but it can be attached a 
flowchart for the description of the computation. It does not support the nested mode and period ex- 
plicitly. However, it is actually an informal modeling notation because it allows to specify the system 
behaviors in natural language. Our MDM is a lightweight formal notation for the modeling with its 
precise operational semantics. 

Giotto is also a periodic-driven modeling language proposed by Henzinger et al. |13|. The main 
difference between Giotto and MDM is the computation mechanism provided. The tasks in a mode 
can be performed in parallel in Giotto while the details of the tasks are omitted and aie moved to the 
implementation stage. The MDM supports the detailed description of the computation in their leaf modes 
since the design of it is targeted for control systems which may involve rich algorithms. The MDM does 
not support the parallel computation explicitly at present since it could bring the nondeterminism at the 
design level. The emphasis of the Giotto is more for the modeling and synthesis of parallel tasks while 
the MDM is for the modeling and verification based on the proposed specification language. 

Runtime Verification is a verification approach based on extracting information by executing the 
system and using the information to detect whether the observed behaviors violating the expected prop- 
erties |[T2l I21I. The verification approach we apply in this paper is also a kind of runtime verification. 
But our methodology is the off-line analysis, while [21] applies an on-line monitoring approach using 
Aspect-J. The reason to propose off-line analysis is that the cost to decide if an ITL formula is satisfiable 
on a given trace is expensive, so information extraction and analysis are separated to two phases in our 
approach. 

6 Conclusion 

In this paper, we propose the Mode Diagram Modeling framework (MDM), a domain-specific formal 
visual modeling language for periodic control systems. To support formal reasoning, MDM is equipped 
with a property specification language based on interval temporal logic and a statistical model checking 
algorithm. The property specification language allows engineers to precisely capture various properties 
they desire, while the verification algorithm allows them to reason about MDM models with respect to 
those properties. The viability and effectiveness of the proposed MDM framework have been demon- 
strated by a number of real-life case studies, where defects of spacecraft control systems have been 
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uncovered in the early design stage. 
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